Internet technology is based on the best-effort paradigm. To fulfill the specific Quality of Experience (QoE) needs of certain applications specific network treatment of their traffic may be required. Such specific network treatment is typically referred to as traffic differentiation.
There are a number of resource sharing methods that may be used for traffic differentiation, which are known in the art. All of these resource sharing methods require that a network entity that performs traffic differentiation knows about a specific traffic characteristics to fulfil. A commonly used way to infer this in current Internet Service Providers (ISPs) is so called Deep Packet Inspection (DPI)-based methods. These methods parse fields on the Internet Protocol (IP) and transport layers but also recognize application related information above transport layer. One can distinguish the DPI function, which inspects characteristic signature, e.g. key string, binary sequence, etc., from Deep Flow Inspection (DFI) function. The DFI function analyzes statistical characteristic and connection behavior of traffic flows, to identify an application. A simplified version of DPI is Shallow Packet Inspection (SPI), which inspects only the packet header, e.g., IP addresses, port numbers or higher level protocol fields.
There are also a number of ways the applications may reveal the required treatment of their traffic. The applications can for example reveal the treatment:                by marking fields, e.g., DiffServ CodePoints (DSCP), Request For Comments (RFC)-4594 in the IP packet headers;        by using some kind of signaling. Both off-path and on-path, out-band or in-band signaling is possible. In 3rd Generation Partnership Project (3GPP) mobile network, receiver/receive (Rx) interface has been defined to allow interaction between Internet Content Providers (ICPs) and ISPs using Diameter protocol. However, currently few ICPs have support for the Diameter protocol. Considering ICP is more familiar with XML based protocol, 3GPP is working on the solutions for an Extensible Markup Language (XML) based protocol, e.g. SOAP, Restful HTTP, etc., over Rx interface between the Application Function (AF) and the Policy and Charging Rules Function (PCRF). Internet Engineering Task Force (IETF) has also standardized a few signaling protocols, like the on-path, out-of-band Respondez s'il Vous Plait (RSVP) (RFC2205) or Next Steps In Signaling (NSIS), Request For Comments (RFC) 4080.        
Traffic differentiation based on packet markings at the network layer, such as with DiffServ, FlowLabel etc., has been limited to single-domain agreements, because of the fact that these packet markings may be easily modified across network domains. Signalling-based solutions for resource reservation have not become popular, mostly because of deployment problems. So operators currently use DPI/DFI/SPI based methods for traffic differentiation. In general, a 5-tuple based traffic identification is sufficient, e.g. the operators and content providers may agree on what ports to use for certain traffic. In the case of client subscriptions for differentiated services, it is possible that the treatment required for a certain 5-tuple is indicated by the client e.g., by DSCP-marking the uplink traffic, e.g., the ACK packets for the same flows; this can then be detected by SPI and the corresponding Quality of Service (QoS) treatment applied for the downlink packets.
There are currently, however, a few trends in networking that have an impact on current practice of operator services.
One relates to the privacy of communication. Accelerated by the recent pervasive monitoring attempts revealed, more and more traffic is sent end-to-end encrypted. One relevant example is the recently finalized Hypertext Transfer Protocol (HTTP) 2.0 protocol in IETF, which assumes de facto encryption using Transport Layer Security (TLS) over Transport Control Protocol (TCP).
Another change relates to the multiplexing of traffic, i.e. multiplexing steams onto one connection. In the case of best-effort handling at the bottleneck, traffic multiplexing between the same endpoints allows for resource sharing that is more aligned with the QoE-needs of the different streams sharing the same connection. This is why HTTP2.0 also uses the multiplexing paradigm. Similarly, the recently proposed next-generation transport protocol by Google, Quick User Datagram Protocol Internet Connections (QUIC) is also based on the multiplexing paradigm. Another example is Web-“Real Time Communication” (RTC), which multiplexes audio, video streams and potential file transfers onto the same User Datagram Protocol (UDP) connection.
It is obvious that DPI/FPI/SPI methods are hardly applicable for encrypted and multiplexed traffic. The same is valid for the signaling based solutions. While assuming, for example, that a voice and a video stream are multiplexed into the same video conference connection, the endpoint should then practically signal for each packet separately which (voice or video) packet requires the treatment for voice of video, respectively, which is a non-scaling solution. The multiplexing requires the ability to signal the required treatment on sub-flow level, e.g., by packet markings.
One could imagine a scenario where the some existing network control solution, e.g., NSIS signaling is used to convey information about which DSCP should be used for which packet markings. A disadvantage is, however, that QoS treatment would have a limited effect on a neighboring domain, due to the uncertainty of using DSCP markings across borders between network domains.